TLDR;

• Time is the only rare commodity, so plan early, and don’t pivot.
• Tech skills don’t matter nearly as much as teamwork and communication.
• Every hackathon is different; first principles thinking is your greatest asset.
• Networking is more valuable than any one thing you’ll build, even when you win .

Pre-yap:

Hackathons are always a wild tossup. You never know if you’ll end up winning.

And yet, I still attend these competitions and try to make an idea come to fruition within an impossibly tight deadline.

This post is an attempt to reconcile the loose list of learnings over the past year of attending 6 hackathons:

• TAMUhack X (January 2024)
• HackSMU VI (October 2024)
• HackTUD XII (November 2024)
• NSBE UH x Meta Hackathon (November 2024)
• Hacklytics (February 2025)
• QVIDTVM x Ion Inaugural Hackday (Feb 2025)

This list is not meant to be an exhaustive and/or a restrictive set of principles for people looking to jump into hacking, but as a list of guide rails that should be heeded and disregarded at the reader’s discretion (I will advise to heed it more times than you disregard, considering these led me to a podium finish 3/6 times, but you do you).

Yap:

So without further ado, and in no particular order, this is what I’ve taken away from the 6 hackathons I’ve Been to:

Time is the only metric that matters

In the hackathon world, time is the one and only constraint. Every hour should be accounted for in your project roadmap, and ideally that plan should be ready before you even step foot in the venue.

Every Hour spent on non-project activities (barring necessities like sleep and food) or crashing out because of too much Caffeine/Sugar is a minute lost to more potential features or a more featured project (See the Caffeine point bellow).

To maximize your time, have multiple project ideas, team member roles, and track preferences ready to go during the opening ceremony. Hit the ground running, because remember: time is the only metric that matters.

Your Team will either be your Vibranium or your Kryptonite

Choose your teammates wisely and carefully, or don’t choose at all. Random team-ups are a gamble that rarely pays off. If you don’t know anyone, flying solo will be your best bet.

Only team up if you’re confident that every member is dedicated, ready to lock in, and genuinely capable of delivering on their promises. Cold and/or Distracted teammates can drag you down, and dysfunctional ones can sink your ship entirely.

Don’t be afraid to cut ties or call out BS – remember, niceness can cost you your project when time is the only metric that matters

Judges: Jury and Executioner

When you face the judges, you’re standing on two legs: your idea and your project.

During pitches, channel your inner salesperson – your product is your project idea, not just the MVP you’ve cobbled together. That MVP should serve as a proof of concept, demonstrating the potential of your idea.

Of course, if you’ve somehow managed to create a near-complete project, you’re already ahead of the game and probably don’t need my advice.

Don’t Focus on the prize if you want to win

Focusing too much on the prize can warp your project design and presentation. Judges can smell a prize-hungry, low-effort, or uncreative project from far away.

Your project needs that special coolness factor, which is easier to achieve when you let go of prize constraints and focus on building something genuinely cool.

Remember to gauge the skill level of your fellow hackers, but as a yardstick, at any decent-sized hackathon (300+ participants), a simple webapp or dashboard won’t cut it. Your idea needs to stand on its own, independent of the project itself. And at hackathons with 700+ people, you better have a great Idea, AND a great project by the end.

And even if you have a great idea and a fantastic project, if you’re not the best salesman of your project, the judges will give the prize to seemingly “less deserving teams” (although my stance is in line with MLH’s: all judging is final. it sucks knowing you didn’t win with a clearly better project, but that feeling only proves my point further)

Soft Skills Matter More Than the Tech Stack

Don’t be a hermit during hackathons. Engage with recruiters, chat up fellow hackers, and participate in fun activities like Bob Ross painting workshops.

These events are a rare concentration of like-minded individuals – make the most of it! This strategy also helps you relax between coding sprints and keeps your body active.

Networking at hackathons can be just as valuable as the project you build. I know multiple people (like 10s of my friends) who wouldn’t have landed internships were it not for their networking during hackathons (some even landed full time roles).

Note: Landing a job is not a result of attending a hackathon or networking, So don’t treat it as a checkbox. Treat it is a chance game. the more you put yourself out there in front of your target clientele (the Recruiters) the better odds and experience you will have of selling the product (your time and expertise, in exchange for a job offer)

Caffeine WILL kill your productivity, and so will not sleeping.

Treat hackathons like marathons, not sprints. Remember, you’ve got real life to return to after the weekend is over.

Sleep, nutrition, and mental breaks aren’t optional – they’re Required. Burnout is real and counterproductive. Limit yourself to 100mg of caffeine per day (~2 cups of black coffee, one early in the morning and one close to noon) and aim for at least 8 hours of sleep for each full day of the hackathon.

Even seasoned senior software engineers can’t maintain peak productivity for more than 4-5 hours a day, and since you’re rarely judged on how much sleep you’ve sacrificed, lock in on building and iterating quickly and zone out everything else.

When you feel your productivity slipping, take a break before you crash – chat with others, catch some Z’s, grab a bite, or go for a quick run. These are ironically the best time to let your mind work on autopilot about the bug you’re experiencing, or that new feature youre thinking of adding.

Final Thoughts

Winning hackathons should be seen as a positive side effect, not the main goal. The real focus should be on pushing your limits, rapid learning, and connecting with fellow tech enthusiasts.

Ironically, I’ve found the most success when I’ve let go of rigid rules and instead focused on tackling simple problems with first principles thinking and iterative ideation.

whats next for me;

• HackKU (April 2025)
• fall 2025: hacktx, hakutd, hacksmu, hackrice, and many more throughout texas!